Systems and methods for overtime parking violation detection

ABSTRACT

Provided is a technology that allows, inter alia, two different patrol-vehicles to be used to enforce parking regulations. Unique systems and methods, inter alia, allow a patrol vehicle or the like to collect parking data pertaining to parked vehicles, and to wirelessly transmit such parking data to a server. A later patrol vehicle or the like can wirelessly receive parking data related to parking events related to its parking enforcement situation and determine whether parking violations, such as overtime or permit sharing violations, are occurring using a combination of parking data generated locally and extraneous parking data collected by the previous patrol vehicle.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.15/780,321 filed on May 31, 2018, that is a 371 application ofInternational PCT application No. PCT/CA2016/051404 filed on Nov. 30,2016 that claims priority on U.S. provisional patent application No.62/261,432 having a filing date of Dec. 1, 2016, the contents of whichare hereby incorporated by reference in their entirety.

TECHNICAL FIELD

The present technology relates to the field of parking enforcementsystem. More particularly the present technology relates to mobile, e.g.vehicle-bound, systems for parking enforcement which rely on dataacquired in situ to ascertain the existence of parking violations suchas the violation of parking rules forbidding a particular length ofstay. The present technology may also relate to operations wheremultiple mobile systems are used.

BACKGROUND

Although the majority of motorists are law-abiding with respect toobeying municipal parking restriction regulations, enough of themroutinely—whether deliberately or not—don't. This causes problems forotherwise law abiding motorists. Therefore parking regulationsenforcement is an important part of the administration of parking areas.

In the past, one aspect of parking regulations enforcement consisted ofensuring a motorist respected maximum parking periods typically by usingchalk to “chalk” the tire of a vehicle and/or the asphalt to ascertainits position and returning some time later to determine whether thevehicle moved in the intervening time period. Other prior art systemsinclude honor based system employing a user-set parking time indicatorsuch as a parking disc.

SUMMARY

Provided are systems, methods and more broadly technology as describedherein.

In accordance with one exemplary embodiment is provided a virtualchalking module for creating locally-created virtual chalking datacomprising location information of a vehicle and at least one additionalinformation, the vehicle-based virtual chalking module comprising aninput for receiving from a remote vehicle remotely-created virtualchalking data.

In accordance with another exemplary embodiment is provided a method ofdetecting parking violation comprising at a first device at a firsttime, generating first parking data concerning a parked vehicle, theparking data comprising location information, time information and avehicle image; at a second device at a second time, generating secondparking data; detecting a parking violation using at least a portion ofthe first parking data and at least a portion of second parking data todetect a parking violation.

In accordance with another exemplary embodiment is provided a method forin-the-field parking enforcement executed on a mobile parkingenforcement device. The parking enforcement device comprises: a) awireless interface for communicating wirelessly with a remote parkingenforcement server, b) a parking data acquisition hardware interface forcommunicating with parking data acquisition hardware for receivingtherefrom parking data pertaining to nearby vehicles, c) a processingdevice in communication with the wireless interface and the parking dataacquisition hardware, and d) computer-readable memory in communicationwith and accessible by the processing device. The method comprises: a)receiving at the wireless interface from said remote parking enforcementserver a set of at least one extraneous past parking events eachcomprising parking data corresponding to a extraneous past parking eventfor a particular vehicle including at least a vehicle identifier for theparticular vehicle and one other parking parameter, b) receiving at theparking data acquisition hardware interface parking data pertaining to anearby vehicle, the parking data comprising at least a vehicleidentifier and one other parking parameter for the nearby vehicle andgenerating at the processing device a parking event using with acquiredparking data, c) at the processing device, searching said at least oneextraneous past parking events and identifying a match between aparticular extraneous past parking event and the parking event generatedat the processing device on the basis of their respective parking dataand determining at least in part on the basis of the parking data of thematched parking events that a parking violation has occurred, and d) atthe processing device generating a violation event and storing saidviolation event in said computer-readable memory.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a perspective view of a parking enforcement system accordingto a particular example, mounted on a patrol vehicle;

FIG. 2A is a block diagram of the parking enforcement system of FIG. 1;

FIG. 2B is a block diagram of a variant of the parking data acquisitionhardware in the parking enforcement system of FIG. 1, according toanother example;

FIG. 2C is a block diagram of a variant of the trunk unit in the parkingenforcement system of FIG. 1, according to another example;

FIG. 3 is a perspective view of the patrol vehicle of FIG. 1 executingparking enforcement with the parking enforcement system;

FIG. 4A is a flow chart describing parking enforcement performed by theparking enforcement system of FIG. 1 according to a particular example;

FIG. 4B is a flow chart describing parking data acquisition by theparking enforcement system of FIG. 1 according to a particular example;

FIG. 5 is a block diagram of a parking event object created by theparking enforcement system of FIG. 1 according to a particular example;

FIG. 6 is a block diagram of a parking management system according to aparticular example;

FIG. 7 is an event flow diagram describing transmission of parking datafrom the parking enforcement system of FIG. 1 to a parking enforcementserver according to a particular example;

FIG. 8 is an event flow diagram describing transmission of parking datafrom the parking enforcement system of FIG. 1 to a parking enforcementserver according to another particular example;

FIG. 9 is an event flow diagram describing the download of extraneousparking data from a parking enforcement server to the parkingenforcement system of FIG. 1 according to a particular example;

FIG. 10 illustrates a screenshot of a user interface showing aconfiguration tool for a patroller service software showing certain useroptions according to a particular example;

FIG. 11 illustrates a screenshot of a user interface of a patrollerservice software showing a navigation pane;

FIG. 12 illustrates a screenshot of the user interface of the patrollerservice software FIG. 10 showing a synchronization window;

FIG. 13 illustrates a rear elevation view of the trunk unit of theparking enforcement system of FIG. 2 showing the connection to two tirecameras through an adapter;

FIG. 14A illustrates a flow chart representing an overtime violationdetection algorithm according to a particular example;

FIG. 14B illustrates a flow chart representing the steps to find anovertime variation step in the algorithm of FIG. 14A; and

FIG. 14C illustrates a flow chart of a permit violation detectionalgorithm according to a particular example.

DESCRIPTION

In a modern parking enforcement system, a patrol vehicle may compriseequipment to photograph a series of parked vehicles, including licenseplates and detailed pictures of the parked vehicles' tires (e.g. tirewell and stem valve), and collects time and location information foreach (e.g. via GPS), combining the two. The same patrol vehicle visitingthe same city block some time later carries out a second data collectionand combination for the series of vehicles encountered during the latterpatrol.

FIG. 1 shows an exemplary patrol vehicle 105 equipped with a parkingenforcement system 100. A block diagram of the parking enforcementsystem 100 is shown in FIG. 2. The parking enforcement system 100comprises parking data acquisition hardware 110 which in this exampleincludes a license plate and context camera 115, a tire camera 120 and aGPS unit 125. In this example, the parking data acquisition hardwarecomprises a trunk unit 111 which aggregates data from various camerasand performs some image processing and analysis, generates plate readevents and configures video streams and data for viewing and processingby the parking enforcement device 101. As the name implies, the trunkunit 111 is typically mounted in the trunk of the vehicle, however thisshould not be regarded as a limitation, as the trunk unit 111 may bemounted elsewhere. The parking enforcement system 100 further comprisesa wireless communication device 130 which, as shown, typically includesan antenna 135. The parking enforcement system 100 of this example alsocomprises a user interface system 140 which includes a display 145 and auser input device 150.

The user interface system 140 of this example comprises a computer 141,which in this example is a laptop computer and more specifically aPanasonic Toughbook® running a Windows® 10 operating system. In thisexample, the display 145 comprises the laptop display and the inputdevice 150 comprises the laptop keyboard, although a skilled person willclearly understand that other input devices may be used/provided andthat external displays may likewise be provided and used.

The parking enforcement system 100 is a mobile parking enforcementsystem 100, which can be moved in order to bring it in situ to thelocation of parked vehicles to monitor and/or enforce parking in thefield. In the example shown in FIG. 1, the parking enforcement system100 is mounted to a standard vehicle, in this case an automobile 106.

The parking data acquisition hardware comprises hardware suitable foracquiring from a nearby parked vehicle, a vehicle identifier. In thepresent example, the license plate ID may be used as vehicle identifier.The license plate ID in this example comprises the unique character(here, numbers and letters) combination of the license plate and mayalso include a license plate context such as the jurisdiction (e.g.state/province/country) of issuance of the license plate. Accordingly,the parking data acquisition hardware comprises hardware suitable foracquiring a license plate number. In the present example, the parkingenforcement system 100 comprises the AutoVu™ automatic license platerecognition (ALPR) system by Genetec Inc. with SharpX cameras, also byGenetec Inc. which capture both color images with a resolution of640×480 and monochrome images captured using infrared camera inresolution ranging from 640×480 to 1280×808. In this example, the SharpXcamera is suited not only to capture vehicle license plates, but alsocontext images showing the vehicle in its parking spot.

Thus the parking data acquisition hardware also comprises hardwaresuitable for acquiring context data, which in this case includes colorimages of parked vehicles. The license plate and context camera 115 alsoserves in this role. The license plate and context camera 115 has acolor camera lens angle allowing the capture of a parked vehicle and itssurrounding when the parked vehicle is nearby the patrol vehicle 105, asshown in FIG. 3. Thus the color image camera in the license plate andcontext camera 115 can capture images showing context in terms of wherethe parked vehicle was parked, in some instances a parking spot numbermarking, and generally gather other visual information which may serveas evidence of a parking violation.

In the example shown in FIG. 1, the parking enforcement system 100actually comprises two license plate and context cameras 115, one foreach side of the vehicle 105. This allows the vehicle 105 to readlicense plates of nearby vehicles on either side of the vehicle 105. Forsimplicity, the system will be described with reference to only onelicense plate and context camera 115 however it will be appreciated thatthe parking data may be obtained from either one, or both, of theselicense plate and context cameras 115. Moreover, additional licenseplate and context cameras 115 may be provided to cover additionalangles.

The parking data acquisition hardware 110 of the parking enforcementsystem 100 of this example further comprises a tire camera 120 whichprovides additional context data. The tire camera 120 is mounted on thevehicle 105 in a location allowing it to capture images of the tires ofnearby parked vehicles. In the example shown in FIG. 1, the tire camera120 is mounted in the fender of the vehicle 105. However, in otherembodiments the tire camera 120 may be mounted elsewhere, such as in abumper or bumper cover of the vehicle 105 or another easily replaceablepart such that providing the tire camera 120 to the vehicle 105 can beaccomplished by installing such a replaceable part having the tirecamera already mounted therein.

As with the license plate and context camera 115, the parkingenforcement system of this example comprises two tire cameras 120, oneon either side of the vehicle 105. This allows the vehicle 105 tocapture images of tires on either side of the vehicle 105. Again forsimplicity, the system will be described with reference to only one tirecamera 120 however it will be appreciated that the tire images may beobtained from either one of these tire cameras 120.

The parking enforcement system 100 of this example comprises parkinglocalisation hardware, in this example the GPS unit 125. The GPS unit125 of this example comprises a GPS antenna and a GPS receiver thatreceives GPS signals from the GPS antenna and computes a spatiallocation based thereon. In alternate embodiments, the GPS unit 125 maybe augmented by a dead-reckoning system such as one that uses anodometer tap to increase the accuracy of GPS localisation.

The parking enforcement system 100 of this example comprises a userinterface system 140 to interface with a user, e.g. a parkingenforcement agent in the vehicle 105, and comprises a display 145 and auser input device 150. In the particular example shown here, the parkingenforcement system 100 comprises a display monitor and a keyboard input.However, in other examples a laptop computer may be provided in thevehicle 105 and may provide the user interface system 140 with itsdisplay and input devices. Other hardware may be used, such as touchscreens or other specialized interface devices, as well as tabletcomputer hardware or the like.

The parking enforcement system 100 comprises a wireless communicationdevice 130 for communicating wirelessly with a remote parkingenforcement server. The wireless communication device 130 of thisexample is a cellular communication device and more particularlycomprises a cell-phone type modem which has internet connectivity over acellular network using the LTE or 3G protocols. Typical embodiments ofthis are what is generally referred to as a 3G router/switch. Thisdevice has enabled cellular capability with a SIM card and acts as awireless internet provider line. This device provides internetconnectivity to the rest of the components in the vehicle's internalcabled network. The enforcement system and Sharp cameras are allconnected to this router/switch and just have internet connectivity. Itis transparent to each device.

In certain embodiments, a VPN channel may be used between the parkingenforcement system 100 and the parking enforcement server 605 (or otherbackend server) to secure any parking data exchanged over the publicinternet. In other embodiment a private and secured dedicated cellularnetwork may be used instead.

FIG. 2A illustrates a block diagram of the parking enforcement system100 according to a first embodiment. As shown the parking enforcementsystem 100 comprises a parking enforcement device 101 which comprisesthe processing logic, memory and interfaces for performing parkingenforcement with the parking enforcement system. In the present example,the parking enforcement device 101 is embodied within the computer 141,which comprises the hardware and software of the parking enforcementdevice 101.

The parking enforcement device 101 of this example comprises aprocessing device 160, which is a general-purpose programmableprocessor, namely in this example an Intel® Core™ i5-4300U vPro™Processor running the Windows® 10 operating system. The parkingenforcement device 101 also comprises computer readable memory 165 incommunication with the processing device 160, which stores programinstructions and data used by the processing device 160.

The computer readable memory 165, though shown as a unitary module forsimplicity may comprise several memory modules. In particular, it maycomprise several layers of memory such as a hard-drive, external drive(e.g. SD card storage) or the like and a faster and smaller RAM module.The RAM module may store data and/or program code currently being,recently being or soon to be processed by the processing device as wellas cache data and/or program code from a hard drive. A hard drive maystore program code and be accessed to retrieve such code for executionby the processing device, and may be accessed by the processing device160 to store parking data.

The parking enforcement device 101 comprises logic configured to performthe steps and interactions described herein. In this particular example,logic is provided by way of configuration of the processing device 160by computer-readable program code stored in the computer-readable memory165. The computer-readable program code implements a patroller service610 in software as described herein. In FIG. 2A, the patroller service610 software is shown within the processing device 160, although it isto be understood that in this embodiment, the program code storing theinstructions for the processing device 160 to implement the software arestored in the computer-readable memory 165.

The parking enforcement device 101 also comprises a user interface 195which communicates with the user interface system 140. The userinterface 195 in this example comprises a video output interface 200 andan input device interface 205 for communicating with the display 145 andinput device 150 respectively. In the present example, since the parkingenforcement device 101 is implemented in the computer 141, the userinterface 195 comprises elements of the computer 141 such as the graphicinterface of the computer and the bus interface used by the keyboard.The video output interface 200 of this example comprises a videoprocessing unit. In alternate examples, the display device may comprisea display that is driven by an HDMI input and is separately powered fromthe vehicle 105's battery with the video output interface 200 comprisingan HDMI interface and port. The video output interface is incommunication with the processing device 160 for receiving therefromcontent to be displayed on the display 145. The video processing unit ofthe video output interface 200 may in certain embodiments share the useof some of the computer-readable memory 165 but in this example it hasits own dedicated high-speed memory (not shown).

The input device interface 205 interfaces with the input device 150, inthis example a keyboard. In embodiments where the input device 150 is anexternal device, such as an external keyboard, the input deviceinterface 205 may comprise a USB connection for connecting with a USBkeyboard. The input device interface 205 is in communication with theprocessing device 160 via a data bus to provide thereto input receivedfrom the input device 150.

The parking enforcement device 101 also comprises a parking dataacquisition hardware interface 170 for communicating with the parkingdata acquisition hardware 110 and particularly for receiving parkingdata therefrom. In this example, the parking data acquisition hardwareinterface 170 may refer to the various data interface(s) used to receiveparking-related data. In the example, parking data is received at thecomputer 141 over an Ethernet connection and the acquisition hardwareinterface 170 comprises the Ethernet interface 171 and the USB interface172 when the GPS unit 125 is connected via USB, as is the case here.

The trunk unit 111 interfaces with the cameras, in this case two tirecameras 120, one on either side of the patrol vehicle 105, and twolicense plate and context cameras 115.

FIG. 13 illustrates the connection ports of the trunk unit 111 inrelation to two tire cameras 120. As shown, the tire cameras 120 areconnected to the trunk unit 111 via an adapter 176 in this examplebecause they have a different connector type than the RJ45 connectoraccepted by the trunk unit 111. The trunk unit 111 comprises a tirecamera interface 175, which provides power to the tire cameras 120 andwhich receives image data therefrom. The trunk unit also comprises anLPR and context camera interface 180, which provides power to the LPRand context camera 115 and which receives image data therefrom. Thetrunk unit 111 has an RJ45 port for connecting with the cameras. Sincethe tire cameras 120 may be units that do not use the same connector, anadapter 176 is provided to suit the tire cameras 120's connectors. Inthis particular example the tire cameras 120 provide an analog signalover a coaxial signal. This is provided to the adapter 176 whichcomprises an analog-to-digital converter and the resulting digitalsignal is then provided to the tire camera interface 175.

The two camera interfaces are in communication with a processing device112, which in this example comprises a general-purpose programmableprocessor running an operating system, in this example Windows® 7embedded. The trunk unit 111 also comprises computer readable memory 114in communication with the processing device 112, which stores programinstructions and data used by the processing device 112.

The license plate and context camera interface 180 is configured tocommunicate with the license plate and context camera 115, specificallyin this example to receive image data therefrom, but which may inalternate examples also provide communications thereto such as commandsto scan or recognize a license plate. In this example, license platerecognition is performed by the processing device 112 based on imagesreceived at the license plate and context camera interface 180 andtransmitted to the processing device 112 via a data bus. In otherembodiments, the parking data acquisition hardware may comprise astandalone license plate reader (or other vehicle identifier detector)which identifies license plate numbers (or other vehicle identifiers,such as permits, RFID tags, etc. . . . ) and provides them via asuitable communication medium, e.g. a USB interface, to the parking dataacquisition hardware interface 170. Returning to the present example, asmentioned the license plate and context camera 115 captures two types ofimages, monochrome and color images, by two separate capture devices, aninfrared camera and a color camera. These may in some embodiments beprovided together, e.g. in synched superframes containing both infraredand color images, however in this example the license plate and contextcamera 115 provides monochrome and color images as separate streams.These may be any suitable connections; in this example they are custommade cable connections that transport power to the camera and datatherefrom. The license plate and context camera interface 180 comprisesa bus interface which receive image data from the infrared and colorcameras and transmits them via one or more data buses to the processingdevice 112.

The computer readable memory 114, though shown as a unitary module forsimplicity may comprise several memory modules. In particular, it maycomprise several layers of memory such as long term persistent storage(e.g. a hard-drive or external drive) or the like and a faster andsmaller RAM module. The RAM module may store data and/or program codecurrently being, recently being or soon to be processed by theprocessing device as well as cache data and/or program code from a harddrive. The long term storage may store program code and be accessed toretrieve such code for execution by the processing device 112, and maybe accessed by the processing device 112 to store data.

The trunk unit 111 comprises logic configured to receive camera datafrom the various cameras, perform image capturing, OCR, analytics, eventgeneration (e.g. plate read) and to transmit event comprising or alongwith other parking or related data to the parking enforcement device 101and more particularly to the patroller service 610 software runningthereon. In this particular example, logic is provided by way ofconfiguration of the processing device 112 by computer-readable programcode stored in the computer-readable memory 114. The computer-readableprogram code implements a trunk unit software 113. In FIG. 2A, the trunkunit software 113 is shown within the processing device 112, although itis to be understood that in this embodiment, the program code storingthe instructions for the processing device 112 to implement the softwareare stored in the computer-readable memory 114.

In order to communicate with the parking enforcement device 101, thetrunk unit 111 comprises an Ethernet interface 173, which allows networkcommunication with the computer 141.

The GPS interface 172 is configured to communicate with the GPS unit125. In this particular example, the GPS unit 125 comprises a GPSantenna and a receiver which comprises GPS logic for receiving GPSsignals and compute a location based thereon. The GPS unit 125communicates with the GPS interface 172 via a suitable medium, here aUSB connection, and transmits location information, here in the form ofNMEA formatted positioning data, to the GPS interface 172. The GPSinterface comprises a USB port and interface and communicates thereceived GPS to the patroller service 610 software running on theprocessing device 160. In alternate embodiments, the GPS logic fordetermining a location based on GPS signals may be provided within theparking enforcement device 101, for example within the GPS interface172. In such a case, the GPS unit 125 may comprise the GPS antenna andthe communication with the GPS interface 172 may be over a shieldedconnection that transmits directly the GPS signals as received. The GPSinterface 172 would then comprise demodulation logic to interpret thereceived signals. While GPS is used in this example, it has already beenmentioned that other types of location hardware may be used, such asdead reckoning systems. Other satellite-based or terrestrialantenna-based location systems may also be used.

The parking enforcement device 101 also comprises a wireless interfacewhich communicates with the wireless communication device. Althoughshown as separate from the parking enforcement device 101, this andother units may be provided on-board or within the housing of theparking enforcement device 101. The wireless communication device ofthis example comprises a cellular network modem for communicating datawirelessly with a cellular network, particularly here using the LTEand/or 3G standard. The Ethernet interface 171 is in communication withthe wireless communication device 130 and provides data to the wirelessmodem to transmit to a remote address, in this case over the internet,and receives data from the wireless modem. Thus in this example theEthernet interface 171 serves as the wireless interface although inother examples a separate interface may be provided to communicate withthe wireless communication device. The wireless communication device 130provides internet connectivity to the connected components. Although inthis example the wireless communication device 130 uses certain cellulardata standards, other wireless communication standards, and other mediasuch as satellite communication may be used in its stead or tocomplement it.

The wireless interface in this example takes the form of the Ethernetinterface 171 which provides routing to and from the wirelesscommunication device 130.

The illustrated example is exemplary only. It is conceivable, forexample that using a particular system-on-a-chip, certain componentsshown separately be integrated with the processing device 160. Forexample, the processing device 160 may comprise software code modulesfor receiving, formatting, interpreting and/or storing data receivedfrom parking data acquisition hardware 110 or the user interface system140 and may include an on-chip video processing unit.

FIG. 2B illustrates a variant of the parking data acquisition hardware110′, whereby the parking data acquisition hardware 110′ comprises aSharp camera, which comprises much of the components of the trunk unit111 of FIG. 2A, including the processing device 112 implementing thetrunk unit software 113, the computer readable memory 114, the tirecamera interface 175 and the Ethernet interface 173.

FIG. 2C illustrates a variant of the trunk unit 111 of FIG. 2A, thetrunk unit 111′, whereby the trunk unit 111′ comprises a navigationsystem which includes the position computing functions of the GPS unit125. The navigation system is connected to a GPS antenna via an antennaport and shielded cable. In this embodiment, the trunk unit 111′introduces positional information into plate read events. The trunk unit111′ may also be configured to provide position information upon requestfrom the parking enforcement device 101.

FIG. 3 illustrates the patrol vehicle 105 performing parkingenforcement. FIG. 4A shows a flow chart of an exemplary parkingenforcement method implemented. At step 404 extraneous past parking datarelated to a nearby vehicle is received from a remote server. In thepresent example, extraneous past parking data, which has been gatheredby another patrol vehicle in the past, is received in batch, for examplebased on the location of the patrol vehicle 105, e.g. based on thepenetrating of a geo-fenced area by the patrol vehicle 105. Thisextraneous past parking data is received from a parking managementserver 605 over wireless communication using a cellular communicationnetwork. Transmission of the extraneous past parking data from theparking management server 605 to the patrol vehicle 105 is described inmore details here. In the present embodiment, the extraneous pastparking data is received in a batch, such that the extraneous pastparking data for multiple past parking events, e.g. all past parkingevents in the last X hours for a particular parking zone, are downloadedat step 404 a.

In this example, the batch download comprises only partial parking data(in this case, license plate/vehicle ID, timestamp, geographicalinformation, parking zone) are downloaded for a group of parking events.This allows the parking enforcement system 100 to have the data requiredto ascertain whether there is a match between a currently parked vehicle(as described in current parking data acquired by the parkingenforcement system) and a past parking event. However, additionalparking data, such as context images, tires images and the like may beomitted from the batch-downloaded parking data in order to reducebandwidth and storage requirements and for other reasons. These detailscan be downloaded later upon request as described herein.

By downloading batch data and storing it in local, quickly-accessiblestorage, the parking enforcement system 100 is able to perform quicklookups for rapid match determinations. This is advantageous; forexample, the patrol vehicle 105 may scan license plates as it drives byparked vehicles (as shown in FIG. 3) and rapidly upon scanning a licenseplate, look up the vehicle license plate in the received extraneous pastparking data to see if there is a match. This rapid match determinationallows for certain conveniences. For example, it may enable the parkingenforcement system 100 to determine parking violations quickly beforethe patrol vehicle 105 has moved past the parked vehicle in questionsuch that a parking ticket can be issued without requiring the patrolvehicle 105 to stop and back up.

In alternative embodiments, downloading extraneous past parking data maybe performed later, and with a specific request for the data. To thatend the parking enforcement system may transmit to the parkingmanagement server 605 a request, e.g. in the manner described herein forbatch data, for extraneous past parking data upon acquisition of currentparking data with the parking data acquisition hardware 110. Thisrequest may comprise some of the current parking data, e.g. a licenseplate number/vehicle identifier, such that the parking enforcementserver 605 may search for specifically past parking data pertaining tothat particular vehicle identifier, and optionally to particular parkingrules (e.g. outside of the allowable time period) and transmit to theparking enforcement system 100 extraneous past parking data relatingspecifically to the parked vehicle, or if none is found, an indicationto that effect. In such a case the step 404 may be located lower in theflow chart of FIG. 4A, after step 410. Indeed, the ordering of the stepsin the flow chart is exemplary as the order certain steps may bemodified in certain variants. In the present embodiment, however, theillustrated example using batch downloads is preferred.

As, shown, and in step 405, the patrol vehicle 105 approaches a parkedvehicle, here a first parked car 305, and the patrol vehicle 105 bringsthe parking enforcement system 100 nearby the first parked car 305.

With the parked car 305 nearby, the parking data acquisition hardware110 acquires parking data pertaining to the first parked car 305 at step410. In this example, the parking acquisition hardware 110, includingthe GPS unit 130, license plate and context camera 115 and tire camera120 can operate rapidly in real time and this operation can take placeeven as the patrol vehicle 105 is still moving.

During data acquisition, an infrared camera in the license plate andcontext camera 115 captures images of the parked car 305's licenseplate. This may be prompted from user input. In one example, the parkingenforcement device is constantly receiving the output of the dataacquisition hardware 110 or part thereof and provides a user with outputbased on the received input. For example, the color camera of thelicense plate and context camera 115 may be continuously capturingimages. A user using the computer 141 may view the feed from the licenseplate and context camera 115, either by accessing a web portal of thetrunk unit 111, if one is provided, over the Ethernet connection, or thepatroller service 610 may connect to the trunk unit 111 and retransmitthe monochrome or color camera feed.

In the present example, the parking data acquisition hardware isconstantly working while enabled, with the license plate and contextcamera 115 providing the trunk unit 111 images, some of which willeventually comprise a license plate image. This occurs at step 410 a.The trunk unit 111 performs license plate detection on the monochromevideo data and when a license plate is read, at step 410 b, it triggersa plate read event, and transmits the license plate data, along withother parking data as described, to the parking enforcement device 101.This particular architecture, with the trunk unit 111 performing platereads and creating plate read events and transmitting them to theparking enforcement device 101 is exemplary and the reader shouldappreciate that the trunk unit 111 and parking enforcement device 101may be merged in alternate embodiments. Optionally other/different datamay be provided with the plate read event. Optionally this process mayalso be manual; when the user sees that the first parked car 305 isnearby, in range of the parking data acquisition hardware 110, and/orthat the parked car 305's license plate is in view, the user may providean input on the input device 150 requesting a license plate read orother parking data acquisition. The input device interface 205 receives,this input and transmits it to the processing device 160, where programcode interprets the input as the instruction and in response engagesparking data acquisition by running corresponding program code modules.In some embodiments, manual triggering of plate acquisition may be used,for example, when the system fails to automatically read a licenseplate.

Thus the processing device 112 engages license plate recognition at step410 b. In this example, the infrared camera is constantly transmittingmonochrome images to the trunk unit 111. This signal is processed by theembedded trunk unit software 113 and only valid license plate readevents are sent to the parking enforcement device 101. License platerecognition is engaged by executing at the processing device 112 programcode instructing the processing device 112 to process the currentinfrared image or images to detect a license plate number. Any suitablelicense plate reading algorithm may be used, which may be performedusing one or more license plate image. In this particular example, theprocessing device 112 executes a license plate recognition module, whichin this example is a program code module, that performs a license platerecognition algorithm to extract the image-space location (specificallyhere, pixel coordinates) of the license plate. The image featureidentification module performs an extraction of a license plate region,a segmentation and recognition of the license plate features, in thiscase license plate characters. The processing device 112 accesses theimage space location of the license plate in the images to obtain theportion of the images featuring the license plate. The processing device112 may then execute under instructions by the license plate recognitionmodule a de-rotation and de-skewing algorithmic logic which it appliesto the license plate image in order to generate a plate image that is aflat (horizontal) rectangle. The license plate recognition module maycomprise algorithmic logic (in this case program code instructions) tocalculate the sum of the image intensity (Y value) columns of the imageand applies it to generate an image intensity profile. The license platereading recognition module outputs a value for the license plate.

The system is able to deal with errors in plate reads,errors/inaccuracies in GPS positioning as well as minor relocations ofthe parked-vehicles. Plate read errors include character additions,deletions and substitutions. This allows compensation for imperfectlicense plate reads. In order to match two plate reads at times T1 andT2, several factors are accounted for including

-   -   The number of optically equivalent characters in the sets of        characters of each read. For example, ABC123 resembles A8C123        since B and 8 are optically similar; and    -   The Levenshtein distance between the two sets of characters. For        example, the Levenshtein distance between ABC123 and ABC124 is        1.

The number of optically equivalent characters and the Levenshteindistance permitted vary as a function of the length of the characterset. In one example AB122 is a five character set and a match may onlyhave 1 optical equivalent and a Levenshtein distance of 1. A 4 characterset match may only have a maximum of 0 optical equivalents and aLevenshtein distance of 0. The objective may be to find the most likelymatch(s) with few or no false positive.

Thus the license plate recognition module is a vehicle identifierdetection module as it determines a license plate number as a vehicleidentifier for the parked car 305. In alternate embodiments, the vehicleidentifier detection module may perform a different vehicle identifierdetection algorithm. For example, it may command external hardware, e.g.an RFID reader, to scan for and/or provide an RFID code. Alternatively,where the vehicle identifier is a permit number, the module may performan optical recognition algorithm on the color (or infrared) image of aparking permit. The license plate recognition module may also be appliedto color images although infrared images are preferred as they have beenfound to present a clearer image of license plates in more conditions,and in this example have higher resolution. The license plate andcontext camera 115 comprises infrared light sources to provide evenbetter conditions for license plate recognition.

In addition to recognizing a vehicle identifier, the license platerecognition module may cause the storing in computer-readable memory oflicense plate image(s) used in the license plate identification ascontext data.

At the parking enforcement device 101, upon receiving a plate readevent, a parking event is created storing therein parking data providedwith the plate read event, at step 410 c. In response to the parkingdata acquisition, the processing device 160 stores context datapertaining to the parked vehicle 305, in this example, one or more colorimages of the parked vehicle 305. This may be performed simultaneouslyor in any order relative to the license plate recognition. This contextdata may be useful in proving guilt when a parking violation iscontested.

In the above example, parking data acquisition was automatic.Particularly, the license plate and context camera 115 is continuouslycapturing images for the detection of license plates, e.g. monochromeimages from the infrared camera, which are received at the parking dataacquisition hardware 110 and analyzed for license plate detection asdescribed. To this end, the trunk unit 111 or parking data acquisitionhardware 110′ repeatedly runs the license plate recognition module (ormore broadly, vehicle identifier detection module) to detect a licenseplate. Every time a new license plate is detected, the remainder of theprocess is engaged, including storage of context data. Alternatively,plate reading may comprise a user prompt for a plate read. However, theuser may optionally have the option to enable or disable the licenseplate reading by providing input at the input device which is receivedand interpreted at the processing device 160 which in response enablesor disables license plate reading. In this embodiment where licenseplate detection is performed outside of the computer 141, this mayinvolve sending an instruction from the computer 141 to disable platereading to the trunk unit 111, but more simply may just involve settingthe parking enforcement device 101 to ignore plate read events. Thus aparking enforcement agent driving the patrol vehicle 105 may engage thesystem only when driving by parked vehicles.

The parking data acquisition hardware 110 (in this example the trunkunit 111) gathers parking data and generates a plate read eventcontaining information related to the plate read. In this context, thisdata comprises a timestamp, the license plate number and additionalanalytics such as the plate state/jurisdiction, a read confidence score,a vehicle make and mode, a relative speed, etc. The parking dataacquisition hardware 110 may also include in or with the plate readevent image data, such as a context image and a plate image. To thisend, the trunk unit software 113 comprises a parking event creationmodule, here in the form of program code which may be stored incomputer-readable memory 114, to create a plate read event. This may beprompted by user input, however in this example, the processing device112 engages the read event creation module in response to detecting avehicle identifier, specifically here a license plate.

The plate read event is then transferred to the parking enforcementdevice 101 still at step 410 b. In alternate embodiments, the trunk unit111 and parking enforcement device 101 functionalities may be mergedonto a single device, e.g. a computer running both the trunk unitsoftware 113 and the patroller service 610 software, or thefunctionality of both could be combined into a single software. In suchcases, the plate read event may be transferred via inter-process orinter-thread communication. At step 410 c, the parking enforcementdevice 101 stores data from the plate read event.

The patroller service 610 software comprises a parking event creationmodule, here in the form of program code which may be stored incomputer-readable memory 165, to create a parking event. The parkingevent typically comprises the parking data from the plate read event,although some data may be omitted, if unnecessary.

In certain embodiments, for example where the parking enforcement system100 is being used to monitor infractions for overtime parkingviolations, it may be necessary to acquire additional parking data suchas tire images, e.g. to compare to a past parking event showing that avehicle has not moved since the past parking event. To that end, at step410 d, the parking enforcement device 101 may supplement the parkingevent with additional parking data, such as tire images acquired fromthe trunk unit 111. This may be prompted by user input, however in thisexample, the processing device 160 engages the read event creationmodule in response to detecting a vehicle identifier, specifically herea license plate.

A parking event in this example is a grouping of data, for example adata structure, comprising data pertaining to an observed parked vehicleat a particular time. Its contents may be adapted to the type of parkingregulations being enforced. In this example, the parking enforcementsystem is used to enforce parking violations such as overtime violation,permit violation and permit sharing. FIG. 5 illustrates the contents ofan exemplary parking event 505.

As shown, the parking event comprises data categorized into two types:parking parameter 510 and context data 516. The parking parameters inthis example include the vehicle identifier, here the license platedata, location identifier(s), and may also comprise one or more permitIDs associated with the parked car 305.

In this particular example, the location identifier is a GPS location asdetermined by the GPS unit 125. The processing device 160 of thisexample comprises a location calculation module that computes thelocation of the parked vehicle 305 on the basis of the location found bythe GPS unit 125, e.g. by applying an offset to account for the distancebetween the GPS unit 125 and the parked vehicle 305 on the basis of theside of the vehicle 105 on which it was detected. In this example, theGPS data is stored as a field in the parking parameters object, howeverin other examples it may be associated with another form of data, e.g.as metadata to an image file or vehicle identifier object.

The system is able to deal with inaccuracies in GPS positions, as theurban-canyons that tall buildings create in city centers often obscurethe GPS satellites and add significant noise to the positioninginformation. To improve the positioning accuracy,—some or all the deadreckoning information available can be used: odometer information,gyroscopic information and patrol-vehicle wheel rotation information.

Another source of variance that may complicate all the matching is minorrelocations of the parked-vehicles. Sometimes the move of theparked-vehicle is legitimate (parked-vehicle departed and returned to aparking position close or identical to the original position). Sometimesthe move is a countermeasure for the chalking and to get around thetime-limited parking regulations. Both of these types of movementscomplicate the reconciliation of the two patrol-vehicles reads of theparked-vehicles. For example, moves may change the order in which theplates are read by each of the patrol-vehicles.

The exemplary algorithms provided herein may use various statisticaltechniques to detect a probable violation of the time-limited parkingregulations. The techniques used may be jurisdiction dependent, thusthey may not all be used together. A rules engine may be defined andadapted to a particular jurisdiction to detect violations.

In other embodiments, the parking enforcement system may comprise aparking spot detector which detects a particular parting location byparking spot ID, e.g. by visual recognition of a parking spot label orby RFID reading. The parking device may accordingly be provided with aparking sport detector interface to communicate with the parking spotdetector and receive parking spot data therefrom.

The parking enforcement device 101 has access to a permit list which arepre-defined permits associated with parking rights. Typically, eachparking permit is associated with one or more vehicle identifier such aslicense plate number. This data is usually contained within a permitlist which is downloaded by the parking enforcement system 100, eitherthrough the wireless communication device or from the parkingenforcement server 605 or provided thereto via a physical connection,e.g. uploaded from a USB key. Each permit is typically associated with ageographical area, and may be defined by a geo-fence. In the presentembodiment, permit lists are separated by geographical areas/geo-fencessuch that a list contains all permits applicable to the geographicalarea. For example, if a business has multiple campuses, each withdifferent permits, there may be different permit lists for each campusand when the patrol vehicle 105 enters the geo-fenced area of onecampus, the patroller service 610 downloads or activates thecorresponding list. In the present embodiment, the patroller service 610software may download or activate a permit list based on GPS location ofthe patroller vehicle 105. When plate reads are performed within thegeographical area, plate read events are matched against permitscorresponding to the permit list for that area. Alternatively, thepermits may be stored and kept active altogether, with the patrollerservice 610 matching plate read events against permits and permitsagainst the geographical area. In alternate embodiments, permit data maybe obtained by other means, e.g. by detecting a permit from the patrolvehicle using an appropriate permit detection technology.

In the parking enforcement system, the permit list is selected (i.e.active) based on the patrol area and the received read event is checkedagainst this list. When a match is found between a vehicle ID and anentry in the permit list, the permit ID may be determined. For example,a permit list where ABC132 is allowed to park in zone A until the end ofthe month. This record is identified as permit ID 123456. If theenforcement vehicle reads DEF456 (not in the list), while the previouslymentioned permit list is active, the system does not determine thepermit ID and a permit HIT is raised, indicating that the vehicle has nopermit. If the system reads ABC123, this plate can be found in thepermit list and its permit ID is determined to be 123456.

Permits may include shared permits where a permit may be shared amongmultiple different vehicles. In some cases, people may purchase onepermit for parking but have multiple vehicles. In order to allow thepurchaser to use either one of their vehicles, the permit may be sharedamongst the two vehicles. In general, shared permits are subject toconstraints, e.g. only one vehicle may benefit from the parking permitat a time, or within a particular time range (e.g. a day). That way if aperson purchases one permit and shares it amongst their two vehicles,they may use one vehicle or another on any given day, but if both arefound parked in the permit parking lot/zone on the same day, a violationhas occurred. For the sake of simplicity, this example will be used whenreferring to shared permits: a permit that is associated with twovehicle identifiers, where only one of the two corresponding vehiclesmay be used in any given day to park in the permitted zone. The readershould understand that more complicated sets of rules related to permitsmay exist, but generally shared permits will be shared amongst pluralvehicles while being subject to one or more constraint. Shared permitenforcement involves verifying that the constraints are respected.

Likewise parking events stored by the parking management server 605 maybe associated with geographic areas or other constraints, such that whenthe patrol vehicle 105 meets a constraint, the parking data associatedwith that constraint are transmitted to the parking enforcement system100. In one particular embodiment, each of the parking events areassociated with a parking zone, which in turn is associated with ageographical area, e.g. a geo-fence. The parking enforcement system 100,may transmit the location of the patrol vehicle 105 to the parkingmanagement server 605, e.g. constantly or when the patrol vehiclechanges zones. When the parking management server 605 determines thatthe patrol vehicle 105 has entered the geographical area associated witha particular zone (or alternatively when the parking enforcementrequests the transmission of past extraneous parking data associatedwith that zone—if for example the parking enforcement system 100self-locates itself within certain zones), the parking enforcementserver 605 identifies the relevant past parking events in that zone andtransmits them, e.g. in redacted form as in step 404 a, to the parkingenforcement system 100. Relevant past parking events may be all pastparking events in that zone, but typically comprises at least oneadditional criterion, such as within a certain timeframe (e.g. past 48hours, or from the last patrol).

The parking parameters also comprise time and date data, which in thisexample is received from the GPS unit 125 and stored as a field in theparking parameters object. In other embodiments, there may be anothertime source. For example, the computer 141 may provide the time sourceand other devices such as the trunk unit 111 may synchronize with thecomputer 141's time.

The parking event may also comprise other data such as data identifyingthe patrol vehicle 105, a user or agent using the parking enforcementsystem 100, and other data. When the parking enforcement system 100 isused to enforce parking time limits, it may be useful to gather contextdata that can prove that a parked vehicle has not moved in a given timeperiod. In the past, parking enforcement officers would chalk mark tiresat a particular location. When they returned after expiration of thetime limit, vehicles with chalk marks in the same location would befound to have not moved as indeed it is particularly unlikely that avehicle parks twice in a same location with the wheels in the identicalorientation. The parking enforcement system 100 is configured to takepictures of vehicle tires where a distinguishing feature, e.g. the valvestem, may likewise be used to ascertain whether the vehicle has beenmoved between readings. While in this example, we talk about tires, thistechnology is not necessarily limited to pneumatic tires and may beapplied more broadly to wheels or other similar structures.

Returning to the example of FIG. 3 and FIGS. 4A, 4B, once license platerecognition 410 b is complete and the license plate recognition returnslicense plate data (e.g. number, and optionally a province or state orterritory or country), the processing device 160 causes the display 145to display a note to the user showing the license plate number. In ourparticular example, this is prompted by the reception at the parkingenforcement device 101 of a plate read event. This is useful, forexample, where license plate reading is automatic as it allows the userto detect if a license plate is passed by without being read.Optionally, an audible cue may be output at an audio output device whichmay be provided, along with a suitable interface, in the parkingenforcement system 100. Optionally, user input can flag an incorrectreading to cause the re-execution of the license plate recognition orcorrect the license plate read by manually typing in the correctcharacters.

In certain embodiments, additional current parking data may be requiredto store as evidence or to determine a parking violation has occurred.Such additional parking data may include (more) context images or tireimages. This is captured at step 410 d, which may be performedoptionally at each parking event (as a substep of step 410) or only whena current parking event matches past extraneous parking data (as asubstep of step 435).

Such as when overtime parking detection is being monitored, upon licenseplate recognition 410 b (though in alternate examples, this may beprompted by other events, such as receiving the user input requestingparking data acquisition), the tire camera 120 begins to capture imagesof the parked vehicle 305's tires as the patrol vehicle 105 is nearby.In this example, the tire image capture is triggered by a license platedetection. For this reason, the tire camera(s) 120 may be mounted nearthe rear of the patrol vehicle 105 such that the license plate can beread first, followed by the tire imaging as the patrol vehicle 105drives past the parked vehicle. In this case while it passes it by. Tothat end, the processing device 160 executes a tire image acquisitionmodule at step 410 d, which receives data from the tire camera 120(which in this example continuously provides it but which alternativelycould also be initiated by the tire image acquisition module).

In this particular example, the parking enforcement device 101 receivesa stream of images over a predetermined displacement of the vehicle andkeeps 1 frame for every particular distance (e.g. 30 cm) ofdisplacement. Not shown FIG. 2 is an odometry system which providestravel distance information, such that the patroller service 610software knows when the vehicle has moved a certain distance.Alternatively, time or GPS distance may be used, although GPS may not beaccurate enough for fine distance measurements. In this example, thepre-defined typical vehicle length is set to 9 meters and the systemcaptures a total of approximately 30 images.

When there is an overtime hit, the operator is presented with two setsof 30 images and must pick the best one which show only the wheel, sincesome images may show the back and front bumper or just the side of thecar. Based on received user input the processing device 160 executingthe tire image acquisition module program code selects the correspondingtire images to store as context data. The operator may then compare thetire images from the two sets and provide input at input device 150indicating whether a match is found. In alternate embodiments, thiscomparison may be automated if suitable algorithms are known.

With the parking data thus collected, the processing device 160 adds theadditional parking data, if obtained at step 410 d, to the parking eventcreated at step 410 c. Alternatively, the creation of the parking eventmay be delayed until after all parking data is collected, includingadditional parking data from step 410 d. In this particular example, theparking event is a data object comprising data and files. In particular,in this example the parking event is a C# object that comprises fieldscontaining vehicle identification data, time and date data, and GPSdata. Files include color images, license plate images and tire images.In this particular example the files are linked by reference to theparking event.

Having completed the read event, the parking enforcement system 100 maythen be moved to another vehicle, e.g. next vehicle 310 to completeanother read event. However, several other steps may take place at thispoint as well.

In particular, the processing device 101 transmits the parking event 505to a parking enforcement server. FIG. 6 is a block diagram of a parkingmanagement system 600. The parking management system comprises a parkingenforcement server 605 which is in wireless communication with themobile parking enforcement system 100 as well as other mobile parkingenforcement systems in other locations such as the second parkingenforcement system 100′. Here the system is illustrated in terms oflogic components. The parking enforcement system 100, which may be thesame system as described above, comprises patroller services 610, whichis the logic implementing the parking enforcement services describedherein, implemented in this example by program code running onprocessing device 160. The parking enforcement system also comprisespatroller storage 615 which is the logical data accessible by thepatroller services, including the parking events stored by theprocessing device 160 in the computer-readable memory 165.

The parking enforcement server 605 comprises a patrol manager service620 and patrol manager storage 625. The parking enforcement server is incommunication with the patroller service 610 and other such serviceslike second patroller service 610′ in the second parking enforcementsystem 100′ in another patrol vehicle. To that end, the parkingenforcement server comprises a data interface for communicating withpatroller services. Conveniently in the present example, since theparking enforcement systems are provided with wireless internetconnection, communication with these systems may be achieved via aninternet connection to which end the parking enforcement server 605 isprovided with a network interface.

The patrol manager service 620 comprises logic effecting patrolmanagement operations as described herein. In this example, the patrolmanager service 620 is implemented by software running on a servermachine. In particular, the patrol manager service 620 may be a programmodule provided within the context of a larger security managementprogram such as Security Center by Genetec Inc.

The patrol manager storage 625 comprises parking data received fromparking enforcement system 100 and other such systems like the secondparking enforcement system 100′ provided on another patrol vehicle. Thepatrol manager service 620 has read and write access to the patrolmanager storage 625 and manages a database of parking data, which inthis example is stored by way of an SQL database. The patrol manager isconfigured, in this example by program code instructions, to createentries in the database to store parking data received from thepatroller services and to retrieve entries previously stored to provideto patroller services.

FIG. 7 is an event flow diagram illustrating the transfer of parkingdata from the parking enforcement system 100, and more particularly fromthe parking enforcement device 101 to the parking enforcement server605.

In the example illustrated here, the trunk unit 111 automaticallydetects license plate numbers in a continuous process. When a licenseplate is detected, trunk unit 111 pushes a plate read 705 to the parkingenforcement device 101 in an electronic message comprising the licenseplate data. This is received at the parking enforcement device 101through the license plate and context camera interface 180 and the datais transmitted to the processing device 160. Alternatively, the plateread 705 may be generated within the processing device 160 by a logicmodule, in this example a program code module that analyzes the outputof the license plate and context camera 115 and identifies licenseplate, e.g. using the algorithm described above.

Upon receiving the plate read 705, the patroller service 610 creates aparking event in a suitable manner such as the manner described herein.The parking event is stored in the patroller storage 615, which in thisexample is implemented in computer-readable memory 165.

However, alongside storing the parking event locally, the parkingenforcement system 100 and more particularly the parking enforcementdevice 101 also sends 715 parking data from the parking event to theparking enforcement server using the wireless interface 190 and thewireless communication device 130. To this end, the parking enforcementsystem 100 establishes an internet connection using the wirelesscommunication device 130. The parking enforcement system 100,specifically here the parking enforcement device 101, retrieves frommemory the parking data to be transmitted and converts it in thisexample to a format suitable for transmission and/or processing at theparking enforcement server 605. In this example the transmission is anetwork transmission over a data network, specifically here theinternet. Accordingly, the parking enforcement system 100, and moreparticularly the parking enforcement device 101, serializes andpacketizes the parking data and addresses it to a network address (e.g.IP address) associated with the parking enforcement server 605. Theparking data is transmitted wirelessly by the network communicationdevice 130 using a networking protocol.

In this example the entire contents of the parking event 505 aretransmitted to the parking enforcement server 605, including parkingparameters 510 and context data 516. However, in alternate only a subsetof the parking data in the parking event 505 may be sent, such as justthe parking parameters 510. Transfer of data to the parking enforcementserver 605 may be split, some of it being transmitted at differenttimes, however in this example entire parking events are transmitted inone go. Also, additional data to the parking data may be transmittedtherewith. For example, a user ID or system ID, the ID of a user, the IDof the system, etc. may also be transmitted with the parking event 505.

In the present example, the patroller storage 615 comprises an internaldatabase of parking events. Parking events contents, e.g. context data,may be references to content located in another database. For example,wheel images may be stored in a SQLite database and be linked to fromparking events in the parking event database.

In the particular present example, the patroller service 610 and patrolmanager service 620 communicate together under a Windows® CommunicationFoundation (WCF) technology to exchange certain data using a persistentconnection. Exchange of parking data may take place over thisarchitecture, however in the present example, in order to avoid havingto initialize a persistent connection to upload a parking event, thecommunication of parking events from the patroller manager service 620to the patrol service 610 takes place using a Representational statetransfer (REST) architecture implemented using the Open Data Protocol(OData). In order to reduce the authentication burden required to securethe connection, the patrol manager service 620 uses a security tokenservice (STS) whereby after an initial authentication, there is a tokenexchange with future communications being transmitted with a token forauthentication confirmation.

Returning to FIG. 7, the patroller service 610 transmits 715 the parkingevent 505 in modified form to the patrol manager service 620 using WCF.The parking data, in this case the parking event 505 is received by thepatrol manager service 620 at the parking enforcement server 605 via thenetwork interface. The patrol manager service 620 may then transform theparking data, in this case to reformat it into a format suitable forstorage in the parking data database implemented in patrol managerstorage 625. The patrol manager service 620 then accesses the patrolmanager storage 625 and stores 720 the parking data, in this case theparking event 505 in modified form in the patrol manager storage 625.

In some instances, parking data may be bulk uploaded. For example, wherewireless connectivity is not constant, parking events may not betransmittable upon capture. To this end, the parking enforcement device101 stores in the computer-readable memory 165 in association with eachparking event therein an indicator as to whether the parking event hasbeen transmitted to the parking enforcement server 605. If connectivityis lost and re-established, the processing device executes program codein response to the re-establishment of connectivity that consults thepatroller storage 615 to identify on the basis of that indicator allparking events that have not been uploaded to the server (see step 810in FIG. 8) and transmits them there to (step 815 in FIG. 8).

Other triggers for transmitting parking data to the server may be used.FIG. 8 illustrates another parking data transmission scheme implementedby the parking enforcement device 101. In this example, user inputtriggers the transmission of parking data from the parking enforcementsystem 100 to the parking enforcement server 605. In this example, auser of the parking enforcement system 100, e.g. an operator in thepatrol vehicle 105, provides input 805 at the input device 150indicative of an instruction to transmit the parking data to the parkingenforcement server 100. The user input is received at the processingdevice 160 via the input device interface 205 and in response programcode retrieving 810 from the patroller storage 615 the unsent parkingevents and effecting the transfer 815 of data as described above isexecuted. In this example, only the parking events found to be notpreviously transmitted to the parking enforcement server 605 aretransmitted. In an alternative example, the user input may also beindicative of a subset of parking data to upload, in response to whichthe processing device 160 executes program code to identify the parkingdata of the subset within the computer-readable memory 165 and transmitsit to the server as described above. Upon receipt the patrol managerservice 620 decodes or modifies the parking data if necessary and stores820 the parking data in the patrol manager storage 625. Optionally, thepatroller service 610 may have multiple upload modes, such as anautomatic mode as described above and a manual modes. It may beconfigured to switch between modes in response to user input comprisingcorresponding instructions. In some examples, a batch upload can betriggered upon connecting to a Wi-Fi® network or a manual upload can bedone by downloading data onto a USB stick and walking it to the server.

Now the parking enforcement device 101 uses stored parking datarepresenting past parking occurrences in order to determine parkingviolations. For example to determine overtime parking violations, theparking enforcement device 101 compares a recent parking event with pastparking event to determine whether a vehicle has occupied a same parkingspot for longer than the allowed period. This constitutes a violationand is determined as such by the parking enforcement device 101.

Provided is a technology that allows, inter alia, two differentpatrol-vehicles to be used to enforce parking regulations. A patrolvehicle may patrol a large number of parked vehicles. In one use case, acustomer wants that a patrol vehicle that is different from the one thatoriginally scanned an area, can continue to enforce parking overtimeviolations in this area. The system provides the ability to have twoseparate patrol-vehicles collaborate to enforce the parking whereby, inone example:

-   -   The first patrol vehicle virtually “chalks” the parked-vehicles        and collects data that might be needed to enforce the        regulations. This information varies from municipality to        municipality.    -   A second patrol vehicle does the “check for chalk” a specific        time-interval later. The time interval is greater than the time        permitted by parking regulations of the given parking spaces.        The second patrol vehicle may at the same time also “chalk” the        vehicle for later use by it or another vehicle.

Traditionally the same patrol-vehicle that “chalked” the parked-vehiclesmust do the “chalk check” patrol because all data needed to do theenforcement is in the patrol-vehicle that chalked the parked-vehicles inthe first place.

However, the present system enables bandwidth optimized communicationsbetween the second and first patrol-vehicles. This may be achieved inone example by direct peer-to-peer communications between thepatrol-vehicles or by means of a central computer system (comprised ofone or more computers) that mediates the communications between the twopatrol-vehicles.

In either case, the communications bandwidth may be optimized by onlyrelaying the information needed to detect the time-limited parkingviolation in the first place (e.g., parked-vehicle plate number, cropparked-vehicle license plate sub-image and GPS coordinates and timestamp of the “chalking” event).

In one example, data from two or more successive collections iscompared. OCR technology is used to recognize and convert license plateinformation into raw alphanumeric text. Processing may be done duringany or all of said collections, and be carried out either within asystem present in the patrol vehicle, or off-site (as in the cloud).Once a vehicle has been identified in real time (e.g. at patrol vehiclespeed) as having overstayed its allotted time for its respective zone,enforcement action (such as issuing a parking ticket) may be taken.Advantageously, the present technology trims unnecessary delays fromaspects of the automation operation and provides improved processingspeed.

To avoid unnecessary bandwidth, only key metadata may be exchanged (e.g.post-OCR license plate characters, certainty interval, GPS coordinates),with original and bandwidth-intensive photographic evidence archived forcases warranted by law, by jurisdiction policy, or to definitivelyassert whether a match has taken place prior to issuing a ticket.

Provided is technology for enforcing parking regulations whereby amobile parking enforcement device determines a parking violationoccurrence on the basis of parking data collected by the parkingenforcement device and extraneous parking data which originates fromanother mobile parking enforcement device. In order to do so, theparking enforcement system 100 and more particularly the parkingenforcement device 101 receives from the parking enforcement server 605extraneous parking data originating from another parking enforcementdevice 101′.

FIG. 9 is an event flow diagram illustrating the parking enforcementdevice 101 receiving extraneous parking data from the parkingenforcement server 605. The parking enforcement device of this exampledoes not obtain all extraneous parking data but rather a subsetpertaining to a particular parking enforcement parameters. Differentparking enforcement parameters may be the object of parking enforcement.In this particular example, parking enforcement is divided into a numberof parking zones. When the patrol vehicle 105 patrols a new parkingenforcement parameter, such when it patrols a new parking zone, a userat the user interface 145 requests extraneous parking data for theparticular parking enforcement parameter, e.g. parking zone. They dothis by providing input 905 at the input device 150 representing aninstruction to download the extraneous parking data from the parkingenforcement server 605. The user input is received at the input deviceinterface 205 and is transmitted to the processing device 160 whereuponit triggers the execution of program code causing the processing device160 to request the extraneous parking data.

In executing the program code instructions, the processing device 160first determines 910 what parking data is required based on the parkingenforcement parameter in play. In this particular example, the userinput 905 comprises instructions indicating a parking enforcementparameter, specifically a parking zone. The parking enforcement device101 may alternatively or additionally itself determine parkingenforcement parameters. In this particular example, the parkingenforcement device 101 consults a lookup table providing the permittedparking time for the particular parking zone provided in the user input905. In this example the lookup table is stored locally incomputer-readable memory 165, but in alternate examples, the parkingenforcement device may use the wireless communication device 130 to seekthe permitted parking time from a service on the internet.

In an alternate embodiment, the parking enforcement device 101 receiveslocation data from the GPS unit 125, and looks up the particular parkingzone in which it is located in a lookup table as described for thepermitted parking time. Where the parking enforcement parameter isdetermined by the processing device like here, the user input 905 neednot provide it and the user interface may be accordingly simplified.

In a variant of this alternate embodiment, the downloading of extraneousparking data is not prompted by user input, but rather the requirementfor such data is determined by the processing device 160 according toits programming. The parking enforcement device 101 may itself determinewhen new extraneous parking data must be request. In one example, thepatroller services implemented by programming of the processing device160 comprises a time tracker that determines the requirement for newextraneous parking data when a certain amount of time has passed, e.g.when the time since the most recent parking data received is approachingthe parking time limit. It may determine this merely on the basis of thetime of the last download, e.g. with a simple time counter, or it mayconsult the parking data stored in patroller storage 615 to do so.

In another example, the patroller service 610, implemented byprogramming of the processing device 160, regularly monitors the GPSlocation of the parking enforcement system 100 based on the input fromthe GPS unit 125 and determines when the parking enforcement system 100enters a new a parking zone and determines the need for extraneousparking data based thereon. Again, the patroller service 610 may alsoconsult the parking data stored in the patroller storage 615 toascertain whether the parking data is required, e.g. whether the storagecontains parking data for the particular new parking enforcementparameters, in this example for the new parking zone.

Thus the patroller service 610 determines what extraneous parking datais required, e.g. as a function of the parking enforcement parameters toenforce.

The patroller service then causes the transmission to the parkingenforcement server 605 of a request 915 for extraneous parking data. Inthis example, the request 915 comprises parameters for the extraneousparking data, in particular here the parking zone. Optionally, thepatrol manager service 620 may additionally perform a determination,similar to determination 910, of what parking data is required. Forexample, the patrol manager service 620 may determine a time frame forthe parking data. In this example, however, the request 915 comprisesall the parameters required.

The request 915 employs RESTful OData protocol. At the parkingenforcement server 605, the patrol manager service 620 comprises a RESTservice 955 which interprets the request 915. Programming in the patrolmanager service 620 then causes a query 920 to a parking eventsrepository 960. The parking events repository 960 queries a databaselayer for accessing parking data from the patrol manager storage 625.Optionally, the parking events repository 960 may comprise a cache ofrecently sought parking data. The parking events repository 960 queriesthe patrol manager storage 625 using the database's protocols andreceives in return parking data 930 which is extraneous to the parkingenforcement system 100. This data may be decoded, modified or formattedto suit the requirements of the REST service 955 to which it is provided935. The REST services serializes 940 the query results and transfersthem in accordance with the REST OData protocol to the patroller service610.

The extraneous parking data 945 is received by the parking enforcementsystem 100 at the wireless communication device 180. It is receivedtherefrom at the parking enforcement device 101 by the wirelessinterface 190. The extraneous parking data 945 is then cached, andprocessed by the processing device 160 to load it into memory. Theprocessing device 160 stores the received extraneous parking data,specifically the (partial) extraneous parking events, incomputer-readable memory 165 in an organized manner according to asearchable structure.

The patrol manager storage 625 comprises a database of parking eventscreated by parking enforcement systems like parking enforcement system100. The parking events are stored in a different form than in thepatroller storages, adapted to the particular database used. In thisexample, in the parking enforcement system 100 and more particularly inthe computer-readable memory 165, the database schema is relational andis comprised of multiple tables that are normalized such that the datafor a single plate read event is spread across multiple related tablesand typically require a junction query.

In the parking enforcement server 605, and more particularly in thepatrol management storage 625, the data is currently stored in a veryflat and denormalized table. This format is optimized for insertion,query and retention processes that are specific to the patrol managerservice 620. In this case, the data of a single plate read event isstored in a single row of a single table with images stored in aseparate table.

The storage schemes in the parking enforcement system 100 and parkingenforcement server 605 and the communication schemes therebetween areexemplary and variants are possible. In this particular embodiment,however, database schemas on both sides are optimized for theirlocalized uses.

When the parking enforcement device 101 requests parking data from theparking enforcement server 605, the parking enforcement server providesin response a subset of the parking enforcement data stored in thepatrol manager storage 625, as described above. In this example, thesubset of data comprises a subset of the parking events, according tothe parking enforcement parameters, as described above. In addition, inthis example, only a subset of these parking events is provided.Specifically, the parking parameters including the vehicle identifier,time stamp, parking zone, and optionally other data are provided. Thisdata is used by the parking enforcement device 101 to determine whetherthere is a potential violation and whether additional data, namely thecontext data is required. Since not all parking events received from theparking enforcement server 605 might result in a parking violationdetection, sending only the parking parameters, and the context dataonly on an as-needed basis saves on bandwidth utilization.

Using parking data acquired locally, and extraneous parking datareceived from the parking enforcement server 605, the parkingenforcement device 101 performs parking violation detections.

Returning to the example of FIG. 4A, having acquired the parking datapertaining to the parked vehicle 305 and created the parking event 505,the processing device 160 executes program code to determine whether theparked vehicle 305 has violated a parking regulation. At step 435, theprocessing device 160 performs a comparison of the past extraneousparking data pertaining to the vehicle 305 and the current parking dataand determines on the basis of the comparison and at least one parkingrule, whether a parking violation has occurred.

Specifically, in this example where past extraneous parking data isreceived in batches, this begins with step 415, where the processingdevice 160 accesses the computer-readable memory 165 to determinewhether there is parking data that matches the parking data in parkingevent 505. In particular, the processing device searches through theparking data in memory, and more particularly searches through thepartial or complete parking events stored therein to identify whether astored parking event matches parking event 505.

Match determination may be ascertained on a number of basis includingsameness or similarity/closeness of some parking data in a storedparking event and the parking event 505. In this particular example, theprocessing device 160 searches through the stored extraneous parkingevents received from the parking enforcement server 605 and compares theparking parameters of each extraneous parking events and the parkingevent 505 to identify a match. The parking enforcement device 101 mayalso consider other parking data. In the present example, the processingdevice 160 similarly processes locally-generated parking events toidentify parking violation based also on readings taken by the parkingenforcement system 100 itself.

A simplified process for match detection will now be described withreference to overtime violation for illustration. FIG. 4B illustratesthe process undertaken by the processing device 160 to identify a matchin an example where parking overtime violations are being detected. Theprocess begins at step 415 a. Match detection may be done on a varietyof bases, which may depend on the type of enforcement being performed(e.g. overtime or shared permit enforcement). For example, in the caseof overtime enforcement, the processing device 160 may search throughthe extraneous past parking data for another parking event having thesame vehicle identifier and location. In the case of shared permitenforcement, the processing device 160 may search for a parking eventhaving a same permit ID and a different vehicle identifier/licenseplate. To do so, the processing device may start by finding thebeginning of the stored parking. The stored parking events, which inthis example are extraneous partial parking events may be stored in alinked data structure with a reference indicating the first object. Atstep 415 b, the processing device 160 determines whether a parking eventwas found. If there were none, the no branch is followed to step 415 j.

The processing device 160 sequentially accesses the past extraneousparking event and retrieves the vehicle identifier stored therein, whichin this example is license plate data. This is used to compare with thelicense plate data of vehicle 305 in the current parking event. If thevehicle ID of the extraneous parking event is stored in a differentformat than that of the parking event 505, translation or conversion maybe performed by the processing device 160 at this step. This is true ofother parking data stored in extraneous parking events. However, in thisexample, the extraneous parking data is converted by the processingdevice 160 upon reception by at the parking enforcement device 101 andas such is already in a form suitable for rapid searching andcomparison. Thus at step 415 c, the processing device compares the valueof the license plate ID of parking event 505 and that of the storedextraneous past parking event. If they are not the same, then it isdetermined that there cannot be a match since the stored extraneousparking event corresponds to another vehicle. The processing device 160then returns to step 415 b.

If the vehicle IDs corresponds, then at step 415 e the processing device160 retrieves the location identifier from the extraneous parking eventand compares it to the location identifier of parking event 505. At step415 f, if they do not correspond, then there cannot be a match, becausealthough it may be the same vehicle, it was found previously parked inanother location. The processing device 160 then returns to step 415 b.Other criteria or rules may be applied. In certain cases, the locationof the vehicle may be compared to ascertain whether it was found not(just) in the same parking spot but in the same position, same blockface or same district, depending on the rules in effect and/orpreferences of the purchaser of the system.

If the location identifiers correspond then at step 415 g, theprocessing device accesses the time and date data from the extraneousparking event and compares it to the time and date data of the parkingevent 505. Specifically, the processing identifier computes the timedifference between the two parking events and ascertains whether thetime difference exceeds the permitted parking period. If it does not, atstep 415 h, then there cannot be a match, since the parked vehicle 305has been found to be previously parked within the allowed period. Theprocessing device 160 then returns to step 415 b.

If the time difference is found to exceed the allowed parking time, thenthere may be a parking violation. A parking violation is determined,wholly or in part, to the comparison of the extraneous parking event andthe parking event 505 as applied against programmed parking rules.

In some embodiments, the processing device 101 may conclude an overtimeviolation on the basis of the above alone, and proceed straight to step436. However, in the present embodiment further processing is involved.

At step 415 i, the processing device 160 creates a hit event, whichrepresents a potential parking violation. The hit event identifiesparking data and/or parking events evidencing the (potential) parkingviolation. In this example, the hit event comprises references to theparking event 505 and the matching extraneous parking event. The hitevent is stored by the processing device 160 in the computer-readablememory 165. Further processing is done to confirm the parking violation.

Although a hit event is recorded at step 415 i, in this embodiment theprocessing device returns to step 415 b to search for more parking eventmatches. There may be other parking events matching parking event 505,which may provide further evidence of the violation, additionalviolations such as violation of multiple time periods, or provideadditional information on the parking violation such as a magnitude ofthe violation (amount of time overrun) which may be pertinent forexample if applicable fines are related to the violation magnitude.

At step 415 b, the processing device ascertains whether there is anotherstored parking event to consider. In this particular example, the datastructure storing the parking events comprises a linked chain of parkingevents and terminates in a null event identifier and step 415 bcomprises verifying whether the current parking event points to anotherinstantiated parking event object. If there is another stored parkingevent, then the processing device proceeds to step 415 c, where itaccesses the next parking event and the above steps are repeated. Shouldanother match be found, then another hit event is created and a hitcounter is incremented to identify the number of hit founds. If nofurther events remain to be considered at step 415 b, then theprocessing device proceeds to step 415 j, where it verifies whether anyhits were found. In this example it does this by ascertaining whetherthe hit counter has a non-zero value. If it does then at step 415 k thenit provides the output hit events as output to the process of FIG. 4B.In this example this occurs in that the program module implementing theprocess returns a positive indication of hits, in this example byproviding the hit counter and a reference to the hit events created. Ifno hits were found, then at step 415 l, the processing device 160provides as output of process of FIG. 4B and indication that no matchwere found. In this example this occurs in that the program moduleimplementing the process returns a negative indication of hits, in thisexample by providing the hit counter value of zero.

Parking events may also be provided with unique parking eventidentifiers generated in one example by the parking enforcement devices.Each parking enforcement device may have a unique code which is usedalong with a non-repeating sequence to provide a unique identifier toeach event. The process of FIG. 4B may also include the step ofverifying, prior to processing a stored parking event that it is notidentical to the parking event 505 and, optionally, to other parkingevents already considered.

The foregoing is a simplified description intended to enable the readerto produce a working system. A more detailed description of an overtimeparking violation detection algorithm is illustrated in FIG. 14A andFIG. 14B, where FIG. 14A represents an overtime violation detectionalgorithm and FIG. 14B illustrates the algorithm implemented in the FindOvertime Violation step of FIG. 14A. In this example, Read ID comparisonis based on a unique identifier of a plate read event, which is used toavoid detecting a violation based on a same plate read event. Plate readsimilarity is based on fuzzy matching logic that considers similaritiesbased on optical character equivalences and character substitutions as afunction of plate number string length. Location similarity is afunction of the overtime rule in effect. Three different comparisons maybe used here: same position with preset distance tolerance, same blockface based on street intersections and same district based on completeparking zone.

It should be noted that the order of steps 415 c-415 h is exemplary andthat the different parking parameters may be performed in a differentorder. Likewise other comparisons and verification may be performed suchas permit data comparisons and other data comparisons and verificationof whether the vehicle (e.g. based on license plate or permit data) isauthorized to park and/or to exceed an allowed time period.

The above description is provided with reference to overtime violationin order to allow the reader to better understand the algorithm. Apermit overtime violation may be considered a subcase of the overtimeviolation where the vehicle 305 has a permit for a certain zone but thepermit only allows the vehicle to be parked for a certain amount oftime. In such a case, an additional step of verifying whether thevehicle identifier is associated with a permit, and the allowed timeperiod associated with the permit may be added.

The algorithm of FIG. 4B may be modified to detect shared permitviolations. In such a case, the vehicle identifier may be looked up inthe permit list at step 415 a, and the permit identifier may be usedinstead of vehicle identifiers in steps 415 c and 415 d. Likewiseinstead of finding and comparing location information at steps 415 e and415 f, the vehicle identifier may be used (and compared to the vehicleidentifier from a extraneous past parking event) to detect whether thesame permit is used with two different vehicles. In terms of time anddate data in steps 415 g and 415 h, the constraints associated with thepermit ID (e.g. no two vehicles may use the same permit on the same dayin the same zone) may be applied. As mentioned above, more complexpermit constraints may be used, with the algorithm being adaptedaccording to the permit constraints.

Here too, this description is a simplification. FIG. 14C illustrates apermit violation detection algorithm, according to another example. Inthis example, a shared permit hit requires that two reads are made inthe same permit zone with the same permit ID and within the maximum timelimit for such a violation. Plate number similarity (with those in thepermit list) is based on fuzzy matching logic that considerssimilarities based on optical character equivalence and charactersubstitutions as a function of plate number string length. A permit hitis raised when the platen umber is not found in the permit list, i.e.when the vehicle is not allowed to park in the zone. A lookup is donefor past reads in the same permit zone which are identified as beinglinked to the same permit ID as the read found in the permit list. If nopast reads are found, the new plate read is tagged with the permit ID ofthe permit record that matches best using the permit matcher settings.The new plate read is tagged with the permit ID identified in the sharedpermit list.

In one example, the permit list comprises entries having the format<plate state>; <plate number>; <permit ID>; <permit category>. The listmay contain the following two records: BC; AAA111; 55; P1 and BC;ZZZ999; 55; P1. In such an example the following exemplary eventsequence may take place:

Plate AAA111 is read (1st read)

Using the permit matcher settings, the plate number read is found to besimilar to AAA111 in the permit list, hence no permit hit is raised.

There are no past reads, hence no shared permit hit can be raised.

Plate read AAA111 is tagged with the permit ID 55 since it is the onlymatching record in the permit list.

Thirty minutes later, plate ZZZ999 is read (2^(nd) read).

Using the permit matcher settings, the plate number read is found to besimilar to ZZZ999 in the permit list, hence no permit hit is raised.

A past read exists (AAA111 with permit ID 55) in the system which wasdone within the maximum limit of (e.g.) 2 hours. Using the shared permitmatcher setting, it is determined that the past read and the new readare two different vehicles.

A shared permit hit is raised between AAA111 and ZZZ999 for permit ID55.

Returning to FIG. 4A, at step 420, the processing device ascertainswhether a match was found based on the output of the process of FIG. 4B,FIG. 14C or FIG. 14A and FIG. 14B. If no match was found, the processingdevice determines that no parking violation occurred at step 425. It mayperform further verifications, e.g. for other types of parkingviolations. For example, both overtime and shared permit violation maybe tested for in sequence (or by separate threads, or the like). In oneexample, the processing device then executes program code for causingthe user interface, specifically the display 145, to provide the user anindication that no violation was found.

In the particular example shown here, upon finding a match between theparking event 505 and an extraneous parking event, the processing deviceperforms further processing using additional parking data related to theextraneous parking event to confirm the violation. In particular theprocessing device uses context data related to the extraneous parkingevent. To this end, at step 430, the processing device causes a requestto be transmitted from the parking enforcement system 100 to the parkingenforcement server 605 for the context data corresponding to thematching extraneous parking event found to match. This requestidentifies specifically the parking event, in this example using theparking event's unique identifier which was provided with the parkingevent data previously provided by the server. The request also specifieswhich parking data is requested which in this case is the context dataincluding context image(s) and tire image(s).

In response to the request the patrol manager service 620 of the parkingenforcement server 605 retrieves the requested parking data from thepatrol management storage 625, performs the necessary transformationsfor transmission, and transmits it to the parking enforcement system 100where it is received by the parking enforcement device 101 at thewireless interface 190. This process may be done similarly to theprocess of requesting from the server, retrieving at the server,transmitting from the server and receiving at the device the parkingevents as described above.

Still within step 435, the processing device 160 executes program codeto perform a parking violation confirmation based at least in part onthe additional parking data received from the parking enforcement server605.

In the present example, the confirmation is a two stage process. At afirst stage (not shown) of confirmation, the processing device causesthe video output interface 200 to drive the display 145 to provide avisual indication that a potential violation was found, and outputs tothe display 145 context data both from the parking event 505 and thematching extraneous parking event(s). In particular, the display 145 maybe caused to display first a color image of the parked vehicle showingthe license plate, and optionally a cropped and zoom monochrome image(taken by the infrared camera) image of the license plate from bothparking events. The processing device 160 then executes code listeningfor user input at the input device 145 indicative of a confirmation thatthe vehicles and plates match.

If the user confirms the plates and vehicles match, a second stage ofconfirmation occurs. At step, 431, the parking enforcement device 101acquires tire images from the parked vehicle 305 as described herein.Although this step is shown as being performed after step 430, it may beperformed earlier in the process, for example tire images may beprovided as after a plate read is received as soon as they areavailable. At the second stage of confirmation, the processing devicecauses the video output interface 200 to drive the display 145 tooutputs at the display 145 tire images from both parking events. If tireimages of more than one tire are stored, tire images for each tire ofeach parking event may be provided. Optionally, where multiple tireimages are stored for a same tire of one or both parking events, theprocessing device may accept input requesting a change of image toanother image of the same tire and/or vehicle and thereby allow the userto cycle through the tire images. The processing device 160 thenexecutes code listening for user input at the input device 145indicative of a confirmation that the tire images match, specifically inthis case that the tire images indicate no movement of the vehiclebetween parking events. In the present example two sets of 30 tireimages from each parking event is presented to the user.

If the confirmation failed at either stage, that is if the user inputindicates no match, then the processing device may execute codedismissing the potential violation, for example here by removing the hitevent(s) and proceeding to step 425.

If the parking violation was confirmed at step 435, then the processingdevice determines that a parking violation has occurred. It may thenproceed to step 450 where a parking violation event is created, whichmay be an object comprising data pertaining to the parking violation,including parking data from the parking events confirming the violation.In the present example, the violation event is a data object thatcomprises an indication of the regulation found to be violated, data onthe parking enforcement system 100 and/or user that determined theviolation, and references to the parking events evidencing the violationand/or the parking data contained therein. The violation event is thentransformed for transmission, including serialization, and transmittedto the parking enforcement server 605 using WCF communications forprocessing by the parking enforcement server 605.

Optionally, the parking enforcement system 100 may also compriseticketing hardware controlled by the parking enforcement device 101 toprint or otherwise emit a parking ticket and the processing device 160may be configured to control the ticketing hardware to emit the parkingticket which the user may then provide to the parked vehicle 305.

At the parking enforcement server 605, the violation event is processed.In one example, it is stored in a persistent storage as evidence andadded to a list of parking violation to process for fine collection.

Other permit detection technologies may be used. For example, RFIDpermits may be scanned with an RFID reader with high reliability.Context images may still be stored, e.g. for evidence in case of acontestation.

Rather than downloading from the parking enforcement server 605 parkingdata in bulk, as described above, parking data may be requested on anas-needed basis. For example at each reading or parking event creation.In certain variants, rather than storing a list of parking events fromthe server, the processing device follows step 410 e by requesting fromthe server, e.g. in the method described above with respect to bulkdownloads, parking events having certain parking data corresponding tothe parking event 505 based on the nearby parked vehicle 305. In such acase, the searching steps 415 b and 415 c may be performed at theparking management server 605 based on parking data transmitted to itfrom the parking enforcement system 100.

Comparing two license plate reads may be based on comparing uniqueelements of the license plate, similarity of license plate number (samelength, same maximum character size), other similarities (same zone,same polygon), similar geographical position (positioned within a samezone, same block face—e.g. with respect to an intersection, samedistrict). There may also be a maximum time allowance between the tworeads (e.g. 12 hours) outside of which a violation is not considered tohave taken place, according to the parking rules.

After a hit is found, the driver of the patrol vehicle may be is alertedas described so that he stops his patrol, and possibly backtracks, toconfirm the violation. To confirm the violation, the patrol vehicle mayrequest additional data from the other patrol vehicle comprising parkingenforcement system 100′ either directly or through one or moreintermediate servers. In the case of direct communication betweenparking enforcement systems, a peer-to-peer network may be establishedto that end. Again, in order to optimize bandwidth, only enoughinformation to confirm the violation is retrieved by thesecond-patrol-vehicle. This information may be jurisdiction dependentand thus may vary per implementation. This may include a series ofpictures of the parked-vehicle's wheels to demonstrate that the vehiclehas not moved by comparing the positions of the wheels stem valves. Ifthe vehicle has moved, it is highly unlikely that the stem valves are inthe same position in the first and second images.

Finally, if the patrol vehicle's parking enforcement agent judges thatthere is likely enough evidence to cite the vehicle for a parkingregulation violation, more detailed information might be requested fromthe first-patrol-vehicle to document the infraction. Such informationmight include higher resolution images of the parked-vehicle. A packagecontaining all the data collected to enforce the parking infraction isgathered and uploaded to a central computer system either in real timeor with deferred time.

The parking enforcement server 605 may comprise one or more dedicatedcomputers, or be a service hosted in a cloud service.

In one implementation, a system comprising a patroller service 610software running on a processing device in a patrol vehicle and acentral server application running on one or more computers whichcomprises a license plate recognition module (or LPR Manager) which hasa managerial role over one or more (typically a plurality of) patrolvehicles and more specifically patroller services 610 is provided. Thesharing of data between patrol vehicles (in this example, betweenpatroller services 610) serves mainly to maintain in all patrollerservices 610 associated with the same LPR Manager role, the readings forspecific areas. Readings may include parking data such as location (e.g.GPS) information, visual information, time information (e.g. time stamp)and identification information (e.g. license plate). The parking datamay also include image data, e.g. partial image data. This ensures thata patroller service 610 has access to recent reads of last X days (aselected or predetermined timeframe) made in the same area by the otherpatroller services 610. The number of days corresponds to the value of“Reads Retention” of the patroller service 610. As described herein,provided is the data transfer but also the user interface of thepatroller service 610, the configuration, the role and the license.

The system provides local readings and shared readings. For the user,there may be no difference visible in the present embodiment in the userinterface about the readings, which may both be presented in the samemanner. In one example, only the local readings are sent to the LPRManager role during the offload of the data from the patroller service610 to the central server and only the patroller service 610 to whichbelongs the most recent reading of a pair may raise a hit.

The data transfer may take place as follows. In order to withstand thescenarios with and without persistent connection, the user is able toconfigure when the data will be downloaded from the central server tohis patroller service 610. He can choose to manually download the datafor specific areas or have them automatically downloaded (via theconfiguration on an event: zone selection, starting the patrollerservice 610 (all reads)). The context images may also be downloaded onrequest (persistent connection) or downloaded with the readings (if theimage is missing, the patroller service 610 will display an image bydefault). The readings downloaded appear in the patroller service 610without differentiation of local readings.

The downloaded data may persist locally as long as space permits andthat the duration of persistence is not reached. In case of lack ofspace, the downloaded data outside the current zone will be erased.

As the quantity of readings transferred can be important, it may be doneby pieces in order to withstand cuts and resumptions of networkcommunication.

If a zone is selected again after the initial download, only thereadings more recent than the last download (by the patroller service610) are imported in this example. The locally-originating readings maybe omitted from download.

The readings that occur (downloaded from central server or otherpatrol-vehicles) while the option “Reads Paused” is active are buffereduntil the option is disabled (i.e. have no appreciable effect on the IUor the workflow).

The readings will be available to the other patroller services 610 fromthe time they will be uploaded to the central server. This may requirein some embodiments an explicit “offload” operation to ensure that the“live” data that could not be routed (cut off the network connectivity)are indeed transferred.

Refer to FIG. 10—FIG. 12 for the user interface and configurationaccording to a particular example of implementation. As shown in FIG.10, a shared tab under an operation category allows a user to selectwhether shared reads are used and whether to automatically downloadshared reads. The trigger for the download may be selected, in thisexample the download trigger is related to zones, e.g. entering a zoneor based on availability of reads in a selected zone. FIG. 11 shows anavigation pane. FIG. 12 shows a synchronization window wherebysynchronization status can be reviewed, e.g. showing read datadownloaded from other patroller services 610.

In terms of the license, the provided feature allowing sharing of readdata may be licensed separately from the license for, e.g., patrollerservices 610, central server application, LPR management, or morebroadly a license for an overall patrol system. The feature may beactivated or deactivated according to the license held by a particularuser and may be based on the number of patroller services 610 allowedwith the functionality. Activation may occur in an XML file thatcontains this and optionally other options.

In one embodiment, the patroller service 610 starts importing on zoneselection and perform follow-up with transfer indicator displayed to theuser.

In case of a power outage, the patroller service 610 may resume datatransfer after the outage. A transfer window and indicator may beprovided to the user in the patroller service 610.

Another feature of the patroller service 610 may be that received andbuffered reads are downloaded when “Reads Paused” option is enabled. Thedownloaded reads may be added in database, they may be added to theworkflow and the user interface may be adjusted accordingly.

The patroller service 610 may automatically delete the downloaded datanot relevant in the case of lack of space by applying a discriminationalgorithm (e.g. when the available space falls below a certainthreshold) to the existing data selecting the data not relevantaccording to a particular criterion or criteria, e.g. pertinence to adistant zone or age of the data.

The patroller service 610 may produce generated images for readsdownloaded without images.

As discussed, the patroller service 610 may download reads on a trigger.Optionally, the patroller service 610 may also download on demand theimages for a read. Information about the source of the read may beincluded in the parking data and may be added in the details pane of theread event. For example, data concerning the patroller service 610,camera, patrol vehicle, time captured etc. of the captured data may beadded and provided alongside the data when downloaded and visuallydisplayed to a user alongside the data.

The patroller service 610 may implement separate statistics of localreads and downloaded reads. It may also exclude reads downloaded fromthe “Offload” operation and/or exclude the reads downloaded from the“Live transfer” operation. As discussed, the patroller service 610 mayimplement a functionality availability/enablement by license to allowselective enablement and disablement of the presently described system.

The patroller service 610 may implement a hit workflow such that a hitis triggered only if the read is local to the patroller service 610.

As for the patroller service 610, it may be provided with logic toimplement the presently described system, including an API to requestthe relevant reads (complete or partial by patroller services 610). Itmay also be provided with a stored procedure to collect the relevantreads (excluding local reads) from a database.

The present provides the ability to share databases amongst vehicle (Ifvehicle equipped with good Internet) if a city has 5 vehicles forexample, one may lay chalk marks and another may go over and pick upexpired time. This provides an ability to share virtual tire chalk. Thusa Patroller A may read a car and a Patroller B may read another car onthe same car and raises the infraction/hit.

Shared reads between patrollers integrates several features ofcommunication between patroller units, e.g. in a peer-to-peer fashion orthrough an interface with a server.

In one example, a customer with a large campus may not be able to coverthe entire campus with one car. It would be impossible to detect ashared permit (whereby two users use a same permit) if the two users areparked at opposite ends of the campus. The present technology allows fordetection using more than one car by allowing multiple patrol vehiclesto share parking data. The patroller systems may comprise permitdetection technology and the parking data may include permit informationfor detecting multiple uses of a same permit.

In one example, the patrol manager service 620 provides a service to thepatroller service 610 which allows it to request reads, hits and imageson demand based on one or more specific search criteria. The service maybe REST based and use the same user authentication as the patroller,meaning that no additional login credentials are required to use theservice. It may not, however, in this example be open to anyone andaccess must be restricted by appropriate measures. Information query maybe based on a variety of criteria including those described herein. Theservice may be provided as an enforced low priority so as to notinterfere with other functions of the patroller system. Instead ofretrieving images upon information requests, an identifier may beprovided instead allowing separate retrieval of images. The amount ofreturned information may be limited in time configurable at the server(e.g. no more than 24-hour worth of data can be returned).

For example:

-   -   The patroller service 610 requests all the reads done in the        past 24 h in a given permit zone,    -   The patroller service 610 request all the hits raised on a given        overtime rule in the past 8 h,    -   The patroller service 610 requests the context image and LPR        image of a specific read, or    -   The patroller service 610 requests the tire images of a specific        read.

In one embodiment the patroller system has the ability to query thepatrol manager service 620 role using a REST service in order toretrieve Reads and Hits that were done within a specified timespan in agiven zone, or for a given rule so that it can generate hits based onreads done by another patroller service 610′. In one example the systemmay:

-   -   Provide an API to query reads or hits based on, e.g., Zone ID        and/or Rule ID,    -   Provide returned read or hit information that is minimal, e.g.        just the plate number, plate state and timestamp,    -   Provide an API to query the detailed information (metadata) of a        specific read or hit id        -   This API might be only invoked when details information is            to be displayed in the patroller service 610,        -   The returned information might not include images,

The API may be secure, versioned and enforce the licensing limitationsof the invoking patroller service 610 (e.g. permit queries accepted onlyfrom permit officers, etc. . . . ). In one example, only patrollerservice 610 software may call this API.

In one embodiment, the patroller service 610 has the ability to querythe patrol manager service 620 role using a REST service in order toretrieve images from existing Reads and Hits, e.g. to generate a hitbased on information read from another patroller service 610′. In oneexample, the system may:

-   -   Provide an API to query images based on, e.g., Read ID and/or        Hit ID,    -   Provide returned images include LPR and Context Image (tire        images are excluded),

In one example, the patrol manager service 620 is configured to receivepatroller wheel images, store them and have them available through theon-demand image service for later retrieval by the same or anotherpatroller service 610. The patrol manager service 620 may be configuredto receive and temporarily store tire images from patroller service 610reads in overtime with wheel images. The patrol manager service 620 maybe able to serve a limited amount of wheel images (maximum 30) for agiven read at the request of a patroller service 610. The patrol managerservice 620 may automatically purge the tire images from its database soas to limit the amount of space used on disk.

For example:

-   -   Patroller A does the first overtime+wheel imaging read on ABC123        @ 9:00, this information is sent either live or offloaded to the        server.    -   Patroller B enters the overtime zone, downloads the previous        read information (excluding all images) and eventually reads        ABC123 @ 16:00 which is passed the 2 h parking limit for that        zone.    -   Patroller B raises an overtime hit and queries the server for        the wheel images captured by Patroller A at the first read.    -   This allows the operator to validate that the car has not moved        since the first read was made and can issue a violation ticket.

In another example, e.g. in a city which has many patrollers, a singlevehicle may be required previously to do both drop chalk and pick upchalk. However, the present system allows the option for different carsto drop and pick up the chalks. So Vehicle 1 (V1) sees a car at T1 anddrops chalk. A different vehicle V2 can then see the car at T2 and issuethe citation.

The ability to share reads across a fleet of patrollers in near realtime may serve the purposes of detecting shared permit violation andovertime violations. In order to decrease the bandwidth and networkload, the system may:

-   -   When doing permit enforcement, only share reads which are        associated to a shared permit, or    -   For overtime violation detection, V2 may only pull tire images        when it has found a hit.

In one embodiment, access to the patrol manager service 620 Reads/HitsREST service is secure so user with unauthorized access cannot retrievethe available information. In one example the system is:

-   -   Protected by user credentials    -   Access to the patrol manager 620 REST service can be given by        user privileges in the parking enforcement server 605.    -   The service may limit the amount of retrievable data by time        (e.g. previous 48 hours maximum).    -   The service may implement a restrictive data query policy. E.g.        to get information, the patroller service 610 must request        something precise like specify which rule it requests the reads        for).

In one embodiment, Reads/Hits REST service may be protected by basicauthentication over HTTPS. To this end, the implementation may include:

-   -   That the REST service receives credential information in message        header. These may include a username, a password, a patroller        service 610 ID, etc.    -   Credential validation may also take into account user        privileges.    -   Support for HTTPS (e.g. including use of directory        certificates).    -   Addition of a port to host service.

In one example the system supports hit redirection from server topatroller. For example, when a patroller service 610 reads a plate andraises a hit, if a hotlist has a notification list and is linked to theserver, then the hit transferred to the server is redirected to thenotification list for other patroller services 610 on other patrolvehicles.

In one example the system supports spreading out indication of newwanted vehicles to patroller services 610. For example, a new wantedvehicle is entered in the server and is sent to patroller services 610that are linked to it for notification of new wanted vehicles. Also anew wanted vehicle may be entered at a patroller service 610 andtransferred to the central server for redirection.

Although the parking enforcement system 100 was described as mounted toa patrol vehicle 105, it may be provided mobility by other means such asby being mounted on a motorcycle, bicycle or backpack.

Although in this example the system was described in the context of apatroller service 610 provided on-board a vehicle, it is to beunderstood that variations may be included. For example, in an alternateembodiment the first or the local or shared readings may be generated ona different physical platform. In one example, the patroller service 610may be provided on a portable computer, such as a smartphone, which hasthe adequate hardware and software systems such as location/positioningsystems and license plate reading systems.

The above description has been provided for the purpose of illustrating,not limiting the invention.

What is claimed is:
 1. A computer-implemented method for detecting anovertime parking violation, the method comprising: obtaining, at aprocessing device, a first parking event created by a first mobileparking enforcement device of a first patrol vehicle, the first parkingevent pertaining to a parked vehicle; obtaining, at the processingdevice, past parking events created by at least a second mobile parkingenforcement device of a second patrol vehicle different from the firstmobile parking enforcement device; identifying, at the processingdevice, at least one past parking event in the past parking events thatmatches with the first parking event; determining, at the processingdevice, an overtime parking violation of the parked vehicle based on thefirst parking event created by the first mobile parking enforcementdevice and the at least one past parking event created by at least thesecond mobile parking enforcement device; and outputting, by theprocessing device, a parking violation event for the overtime parkingviolation.
 2. The method of claim 1, wherein the first parking eventcomprises a license plate identifier of the parked vehicle, and whereinthe at least one past parking event comprises the license plateidentifier of the parked vehicle.
 3. The method of claim 2, whereindetermining the overtime parking violation comprises: generating atentative violation event representing a potential parking violationbased on the license plate identifier of first parking eventcorresponding to the license plate identifier of the at least one pastparking event; outputting the tentative violation event to a computingdevice; receiving a confirmation that the potential parking violation isa parking violation from the computing device; and generating theparking violation event in response to the confirmation.
 4. The methodof claim 3, wherein the computing device is the first mobile parkingenforcement device.
 5. The method of claim 2, wherein identifying the atleast one past parking event that matches with the first parking eventcomprises searching for one or more past parking events with the licenseplate identifier corresponding to the license plate identifier of thefirst parking event.
 6. The method of claim 5, wherein determining theovertime parking violation comprises: calculating a time differencebetween the first parking event and the at least one past parking event;and determining the overtime parking violation when the time differenceexceeds a permitted parking period.
 7. The method of claim 5, whereindetermining the overtime parking violation comprises: calculating a timedifference between the first parking event and the at least one pastparking event; confirming that a location of the parked vehicle of thefirst parking event corresponds to a location of the parked vehicle ofthe at least one past parking event; and determining the overtimeparking violation when the time difference exceeds a permitted parkingperiod and the location of the parked vehicle of the first parking eventcorresponds to the location of the parked vehicle of the at least onepast parking event.
 8. The method of claim 1, wherein obtaining thefirst parking event comprises receiving the first parking event over anetwork from the first mobile parking enforcement device, and whereinobtaining the past parking events comprises receiving one or more of thepast parking events over the network from at least the second mobileparking enforcement device.
 9. The method of claim 1, wherein outputtingthe parking violation event comprises transmitting, by the processingdevice, the parking violation event to a computing device.
 10. Themethod of claim 9, wherein the computing device is the first mobileparking enforcement device.
 11. The method of claim 1, whereinoutputting the parking violation event comprises storing, by theprocessing device, the parking violation event in a computer-readablememory.
 12. The method of claim 1, wherein the overtime parkingviolation is determined in real-time while the first patrol vehicle isnearby the parked vehicle.
 13. A parking enforcement server comprising:at least one processing device; and at least one non-transitorycomputer-readable memory having stored thereon program instructionsexecutable by the at least one processing device for: receiving, over anetwork, a first parking event from a first mobile parking enforcementdevice of a first patrol vehicle, the first parking event pertaining toa parked vehicle; receiving, over a network, past parking events from atleast a second mobile parking enforcement device of a second patrolvehicle different from the first mobile parking enforcement device;identifying at least one past parking event in the past parking eventsthat matches with the first parking event; determining an overtimeparking violation of the parked vehicle based on the first parking eventcreated by the first mobile parking enforcement device and the at leastone past parking event created by at least the second mobile parkingenforcement device; and outputting a parking violation event for theovertime parking violation.
 14. The server of claim 13, wherein thefirst parking event comprises a license plate identifier of the parkedvehicle, and wherein the at least one past parking event comprises thelicense plate identifier of the parked vehicle.
 15. The server of claim14, wherein determining the overtime parking violation comprises:generating a tentative violation event representing a potential parkingviolation based on the license plate identifier of first parking eventcorresponding to the license plate identifier of the at least one pastparking event; outputting the tentative violation event to a computingdevice; receiving a confirmation that the potential parking violation isa parking violation from the computing device; and generating theparking violation event in response to the confirmation.
 16. The serverof claim 15, wherein the computing device is the first mobile parkingenforcement device.
 17. The server of claim 14, wherein identifying theat least one past parking event that matches with the first parkingevent comprises searching for one or more past parking events with thelicense plate identifier corresponding to the license plate identifierof the first parking event.
 18. The server of claim 17, whereindetermining the overtime parking violation comprises: calculating a timedifference between the first parking event and the at least one pastparking event; and determining the overtime parking violation when thetime difference exceeds a permitted parking period.
 19. The server ofclaim 17, wherein determining the overtime parking violation comprises:calculating a time difference between the first parking event and the atleast one past parking event; confirming that a location of the parkedvehicle of the first parking event corresponds to a location of theparked vehicle of the at least one past parking event; and determiningthe overtime parking violation when the time difference exceeds apermitted parking period and the location of the parked vehicle of thefirst parking event corresponds to the location of the parked vehicle ofthe at least one past parking event.
 20. The server of claim 13, whereinoutputting the parking violation event comprises transmitting theparking violation event to a computing device.
 21. The server of claim20, wherein the computing device is the first mobile parking enforcementdevice.
 22. The server of claim 13, wherein outputting the parkingviolation event comprises storing the parking violation event in the atleast one non-transitory computer-readable memory.
 23. The server ofclaim 13, wherein the overtime parking violation is determined inreal-time while the first patrol vehicle is nearby the parked vehicle.